The Garp Architecture and C Compiler

62 Computer The Garp Architecture and C Compiler V arious projects and products have been built using off-the-shelf field-programma-ble gate arrays (FPGAs) as compute accelerators for specific tasks. Such systems typically connect one or more FPGAs to the host computer via an I/O bus. Some have shown remarkable speedups, albeit limited to specific application domains. Many factors limit the general usefulness of such systems. Long reconfiguration times prevent acceleration of applications that spread their time over many different tasks. Low-bandwidth paths for data transfer limit the usefulness of such systems to tasks that have a high compute-to-memory-bandwidth ratio. In addition, standard FPGA tools require hardware design expertise beyond the knowledge of most programmers. To address the bandwidth problems, some developers have proposed integrating specially designed rapidly reconfigurable hardware more closely with the processor. To help investigate this idea we designed our own architecture in detail, called Garp, 1 and experimented with running applications on it. We are also investigating whether Garp's design enables automatic, fast, effective compilation across a broad range of applications. Our results so far have been promising. Garp combines a single-issue MIPS processor core with reconfigurable hardware to be used as an accelerator. We designed both the reconfigurable hardware and the interfaces among the system components, tailoring them for general-purpose computing. Garp is designed to fit into an ordinary processing environment that includes structured programs, subroutine libraries, context switches, virtual memory, and multiple users. The Garp chip does not exist as real silicon. We have, however, completed critical parts of the integrated circuit layout and performed circuit simulation to give us good estimates of Garp's clock speed, power consumption, and silicon area for a sample implementation. We designed Garp with the intent that its reconfig-urable hardware would accelerate loops of general-purpose programs. This goal led to the following decisions about Garp: • We decided that a few cycles of overhead for transferring data between processor registers and the reconfigurable hardware would be acceptable, since this overhead would occur only at the entrance and exit of loops. • The reconfigurable hardware needed its own direct path to the processor's memory system, since most nontrivial loops operate over memory data structures. Relying on the main processor to shuffle data between the reconfigurable hardware and memory would be unacceptable; the processor would act as a bandwidth bottleneck and also add cycles of latency to every access. • The reconfigurable hardware …